chore(deps): update dependency fantomas to v8 by renovate[bot] · Pull Request #40 · Shadowsocks-NET/Aurum

renovate · 2026-09-15T18:31:58Z

This PR contains the following updates:

Package	Change	Age	Confidence
fantomas (source)	`6.2.3` → `8.0.5`

fsprojects/fantomas (fantomas)

Improved formatting performance. Formatting the source files of dotnet/fsharp allocates around 40% less memory and is roughly 1.4 times faster than 8.0.4, depending on hardware. The fields of WriterEvent, returned by CodeFormatter.GetWriterEventsAsync, are renamed so that cases share them: text for the strings, amount for IndentBy and UnIndentBy, column for the indent and column cases, and nodeType and range for NodeEnd. #3499
Update FCS to 'Record the range of the exceptionin SynExceptionDefnRepr', commit 349d6aa #3500

Comment between doc comment and exception keyword gets shifted. The syntax tree had no range for the exception keyword, so a comment between the XML doc or attributes and the keyword was placed in front of the exception name, after the keyword. The parser now records that range, and the comment stays in front of the keyword. #3483

Improved formatting performance. Formatting the source files of dotnet/fsharp allocates around 40% less memory and is roughly 1.4 times faster than 8.0.4, depending on hardware. The fields of WriterEvent, returned by CodeFormatter.GetWriterEventsAsync, are renamed so that cases share them: text for the strings, amount for IndentBy and UnIndentBy, column for the indent and column cases, and nodeType and range for NodeEnd. #3499
Update FCS to 'Record the range of the exceptionin SynExceptionDefnRepr', commit 349d6aa #3500

Comment between doc comment and exception keyword gets shifted. The syntax tree had no range for the exception keyword, so a comment between the XML doc or attributes and the keyword was placed in front of the exception name, after the keyword. The parser now records that range, and the comment stays in front of the keyword. #3483

Second block comment on a line is lost and the next expression moves onto the comment line. A line that holds several comments and no code, such as (* b *) (* c *), was read as one block comment next to code per comment, and there was no code on that line to attach them to. The first one ended up in front of the next expression, pulling it onto the comment line, and the others were dropped. Such a line is now one comment on a line of its own, printed as it was written. #3487
Idempotency problem when a comment follows a multiline infix expression in a let binding. A comment on its own line after c + and d, at the column of both, was attached to d rather than to c + d. That made the expression multiline, so the operator moved to the start of the next line, and on the next format the comment went to the whole expression and it was joined onto one line again. An indented comment now goes after the outermost preceding node that starts a line at its column, and only falls back to a node further along a line when there is none. #3488

Code comment inside match-expression leads to additional blank line. A comment that ends the multi-line body of a match clause, and then any blank lines the author kept after it, came out with one blank line more than the source had. The same happened before else, finally, end and the next field of a record, whenever the indented body before them ended in a comment. Since 8.0.0 the unindent that closes such a body leaves the comment's newline at the very end of what was written, and the separator the enclosing construct writes next then opened a second line. Those separators now skip their newline when the comment already wrote one, as the closing brace of a record has done since 8.0.0. Blank lines the author kept, and the ones Fantomas puts between multi-line members and bindings, are unchanged. #3484

Remove TailCall shim from Fantomas.FCS. #3476
Fantomas 8 with use bindings in fsx-file. A use at the top level of a script makes the parser warn that it is treated as let, and the check Fantomas runs over its own output refused the file on that warning. The warning is about the source as the author wrote it, not about anything the formatter changed, so it is now one of the warnings the check tolerates. #3478
Unexpected de-indent after trivia after expression. A comment at the end of a match that closes a computation expression, or a let body, pushed the closing brace and the next binding one level too far to the right. The unindent before the closing line was placed in front of the comment's newline, where the match still held the column it had claimed and restored its own indent on the way out, undoing the unindent. The newline now moves past those restores, so the line after the comment starts at the outer level. #3481